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Software  in  modern  embedded  systems  is  often  realised  by  using  prefabricated  reconfigurable  computing  devices  such  as  Field 
Programmable  Gate  Arrays  (FPGAs).  Such  devices  support  the  use  of  portable  hardware  description  languages  and \  as  a 
result,  have  vulnerabilities  consistent  with  normal  software  applications.  In  this  article,  we  consider  the  nature  of  adversarial 
reverse-engineering  attacks  in  this  environment  and  measures  of  protection. 


In  our  modern  world,  the  meaning  of  a 
word  can  change  quite  often.  Even  the 
term  computer  previously  referred  to  a 
human  operator  who  crunches  numbers 
while  today  we  relate  this  term  clearly  to  a 
machine.  With  the  emergence  of  new 
reconfigurable  computing  technologies 
such  as  FPGAs,  the  definitions  of  soft¬ 
ware  and  hardware  have  become  less  clear. 
As  Vahid  suggests  [1],  we  should  stop  call¬ 
ing  circuits  hardware  and  start  broadening 
what  we  consider  software. 

In  the  traditional  sense,  software 
referred  to  the  bits  (Is  and  Os)  represent¬ 
ing  language  statements  that  could  be  exe¬ 
cuted  on  hardware  processors.  Today, 
embedded  systems  utilizing  FPGAs  real¬ 
ize  circuits  merely  by  downloading  a 
sequence  of  bits  that  instantiate  gates, 
controllers,  arithmetic  logic  units,  crypto 
circuits,  and  even  processors.  Thus,  a  cir¬ 
cuit  implemented  on  embedded  systems 
utilizing  an  FPGA  is  essentially  software. 

Considering  the  proliferation  of 
embedded  systems  with  reprogrammable 


hardware  components  in  both  commercial 
and  military  sectors,  we  can  readily  show 
the  impact  of  malicious  activity  geared  to 
reverse  engineer,  tamper,  or  copy  critical 
technologies  residing  in  those  systems.  In 
this  article,  we  delineate  protective  trans¬ 
formations  for  such  embedded  logic  and 
present  a  brief  survey  of  reverse  engi¬ 
neering  attacks  in  this  realm. 

Characterizing  Circuit 
Protection 

Both  the  DoD  and  the  commercial  sector 
have  an  interest  in  describing  and  measur¬ 
ing  candidate  protective  measures, 
whether  they  derive  from  hardware  anti¬ 
tamper  realizations  or  software-based 
techniques.  Adequately  defining  criteria 
for  successful  software  protection  in  prac¬ 
tice  remains  elusive  mainly  because  full 
protection  may  not  be  possible,  at  least 
theoretically  [2].  Collberg  and  Thombor- 
son  [3]  describe  three  practical  means  of 
protecting  software  against  copying, 
reverse-engineering,  and  malicious  tam¬ 


pering;  these  include,  respectively,  water¬ 
marking,  obfuscation,  and  tamper-proof¬ 
ing.  In  terms  of  analyzing  protection 
mechanisms,  they  suggest  measuring 
obfuscating  transformations  based  on 
their  obscurity  (how  much  time  is 
increased  for  understanding  and  reverse 
engineering),  resilience  (difficulty  for 
reversing  the  transformation),  stealth  (the 
natural  context  of  the  transformation), 
and  cost  (overhead). 

Though  embedded  systems  may 
encompass  a  wide  variety  of  custom 
processors  and  components,  our  discus¬ 
sion  focuses  on  more  fundamental  logic 
programs  represented  as  combinations  of 
gate-level  logic.  In  describing  such  cir¬ 
cuits,  we  use  two  primary  analysis  para¬ 
digms:  how  they  behave,  and  how  they  are 
constructed.  We  express  the  black-box 
behavior  of  a  circuit  by  enumeration  of 
all  inputs,  subsequent  evaluation  and 
propagation  of  signals  on  all  intermediate 
gates,  and  the  recording  of  the  corre¬ 
sponding  output.  Figure  1  illustrates  an 
input/output  representation  of  a  small 
combinational  logic  circuit  with  three 
inputs  (XI,  X2,  X3),  four  intermediate 
gates  (4,  5,  6,  7),  and  two  distinguished 
intermediate  gates  (Y6,  Y7)  known  as  out¬ 
puts. 

We  define  a  signal  as  a  vertical  reading 
of  a  column  in  the  truth  table  (a  fully  enu¬ 
merated  input/ output  behavior,  based  on 
canonical  ordering  of  inputs)  and  call  the 
signature  of  a  circuit  the  collection  of  its 
output  signals.  Given  the  full  truth  table 
of  a  circuit,  we  define  its  gray-box  behav¬ 
ior  as  signals  of  all  intermediate  logic 
gates  based  on  the  enumeration  of  all 
possible  inputs. 

The  white-box  structure  of  a  circuit 
may  be  represented  by  textual  description 
languages  (Bench,  Verilog,  VHDL,  etc.), 
which  are  regular  grammars  that  support 
expression  of  gates,  electrical  signals, 
components,  and  gate  interconnections. 
Textual  representations  translate  into 
graphical  forms,  which  are  referred  to  as 


Figure  1 :  Black-Box  and  Gray-Box  Gircuit  Behavior 

Gray-Box  Behavior 

1 


r 


XI 

X2 

X3 

4 

5 

Y6 

Y7 

■ 

i  AND{3,2) 

OR(4,l) 

XOR(4,3) 

NAND(5,6) 

0 

0 

0 

0 

0 

0 

1 

0 

0 

1 

0 

0 

1 

1 

0 

1 

0 

0 

0 

0 

1 

0 

1 

1 

1 

1 

0 

1 

1 

0 

0 

0 

1 

0 

1 

1 

0 

1 

0 

1 

1 

0 

1 

1 

0 

0 

1 

0 

1 

1 

L 

1 

1 

0 

1 

Black-Box  Behavior 


4  CROSSTALK  The  Journal  of  Defense  Software  Engineering 


September/ October  2009 


Report  Documentation  Page 

Form  Approved 

OMB  No.  0704-0188 

Public  reporting  burden  for  the  collection  of  information  is  estimated  to  average  1  hour  per  response,  including  the  time  for  reviewing  instructions,  searching  existing  data  sources,  gathering  and 
maintaining  the  data  needed,  and  completing  and  reviewing  the  collection  of  information.  Send  comments  regarding  this  burden  estimate  or  any  other  aspect  of  this  collection  of  information, 
including  suggestions  for  reducing  this  burden,  to  Washington  Headquarters  Services,  Directorate  for  Information  Operations  and  Reports,  1215  Jefferson  Davis  Highway,  Suite  1204,  Arlington 

VA  22202-4302.  Respondents  should  be  aware  that  notwithstanding  any  other  provision  of  law,  no  person  shall  be  subject  to  a  penalty  for  failing  to  comply  with  a  collection  of  information  if  it 
does  not  display  a  currently  valid  OMB  control  number. 

1.  REPORT  DATE 

2009  ^  REPORT  TYPE 

3.  DATES  COVERED 

00-09-2009  to  00-10-2009 

4.  TITLE  AND  SUBTITLE 

Considering  Software  Protection  for  Embedded  Systems 

5a.  CONTRACT  NUMBER 

5b.  GRANT  NUMBER 

5c.  PROGRAM  ELEMENT  NUMBER 

6.  AUTHOR(S) 

5d.  PROJECT  NUMBER 

5e.  TASK  NUMBER 

5f.  WORK  UNIT  NUMBER 

7.  PERFORMING  ORGANIZATION  NAME(S)  AND  ADDRESS(ES) 

Air  Force  Institute  of  Technology  , Department  of  Electrical  and 

Computer  Engineering, 2950  Hobson  Way,Wright-Patterson 

AFB, OH, 45433-7765 

8.  PERFORMING  ORGANIZATION 

REPORT  NUMBER 

9.  SPONSORING/MONITORING  AGENCY  NAME(S)  AND  ADDRESS (ES) 

10.  SPONSOR/MONITOR’S  ACRONYM(S) 

11.  SPONSOR/MONITOR’S  REPORT 
NUMBER(S) 

12.  DISTRIBUTION/AVAILABILITY  STATEMENT 

Approved  for  public  release;  distribution  unlimited 

13.  SUPPLEMENTARY  NOTES 

14.  ABSTRACT 

15.  SUBJECT  TERMS 

16.  SECURITY  CLASSIFICATION  OF:  17.  LIMITATION  OF 

ARSTRATT 

1 8 .  NUMBER  1 9a.  NAME  OF 

OF  PAGES  RESPONSIBLE  PERSON 

a.  REPORT  b.  ABSTRACT  c.  THIS  PAGE  Same  aS 

unclassified  unclassified  unclassified  Report  (SAR) 

5 

Standard  Form  298  (Rev.  8-98) 

Prescribed  by  ANSI  Std  Z39-18 


Considering  Software  Protection  for  Embedded  Systems 


1NPUT(3) 

J1MPUT(2) 

INPUT(l) 

QUTPUT(7} 

0UTPUT(6) 


4  =  AND(3,2) 

5  =  GR(4,1) 

6  =  XOR{4,3) 

7  -  NAND(5f6) 

Figure  2:  White-Box  Circuit  Description 


the  circuit  topology.  Figure  2  illustrates 
the  circuit  seen  in  Figure  1  in  correspond¬ 
ing  graphical  representation  and  a  Bench 
textual  description  [4].  We  define  a  com¬ 
ponent  within  the  circuit  as  a  collection  of 
lower-level  elements  (such  as  gates)  that 
form  a  distinct  sub-circuit. 

The  semantics  (or  black-box  behavior) 
of  a  circuit  consists  of  only  the  input  and 
output  signal  pairs  (the  X  and  Y  signals 
seen  in  Figure  1).  Intuitively,  one  way  to 
think  of  circuit  protection  is  the  act  hiding 
all  intermediate  transitions  that  transform 
input  to  output.  The  collection  of  these 
transitions,  in  essence,  represents  the 
intellectual  property  of  a  circuit.  Without 
knowledge  of  the  original  intermediate 
transitions,  no  human  or  automated 
process  may  derive  other  information 
about  the  original  circuit  such  as  topology, 
signal  definitions,  or  component  defini¬ 
tions.  Many  define  the  essence  of  circuit 
reverse  engineering  as  the  ability  to  cor¬ 
rectly  identify  topology  or  components  of 
the  original  circuit  [4,  5]. 

To  protect  a  circuit,  replace  the  origi¬ 
nal  circuit  with  a  semantically  equivalent 
version  (one  which  does  the  same  func¬ 
tion)  that  hides  the  intellectual  property  of 
the  original  in  some  definable  or  measur¬ 
able  way.  For  the  circuit  in  Figures  1  and 
2,  a  replacement  circuit  would  have  iden¬ 
tical  signals  for  inputs  and  outputs  (XI, 
X2,  X3,  Y6,  Y7 ),  but  would  have  some 
other  internal  white-box  construction 
(represented  by  gates  4  and  5  in  Figures  1 
and  2). 

This  formulation  restates  the  essence 
of  a  virtual  black  box  [2]  because  it 
defines  full  protection  as  a  replacement 
circuit  that  does  not  leak  any  more  infor¬ 
mation  relative  to  an  original  circuit  (other 
than  its  input/output  characteristics).  In 
more  practical  settings  [3],  the  goal  of 
using  a  replacement  circuit  becomes 
obscuring  the  original  circuit  in  some  way 
so  that  the  cost  of  reverse  engineering  is 
maximized  while  operation  characteristics 
of  the  circuit  are  not  degraded  beyond  an 
acceptable  level.  Next,  we  delineate  the 
permissible  transformations  on  a  circuit 
when  obfuscation  is  in  view. 

Characterizing  Circuit 
Transformations 

We  define  an  obfuscating  transformation 
O(')  as  an  efficient,  terminating  program 
that  takes  circuit  P  as  input  and  returns 
another  circuit  P’:  0(P )  —  P\  Of  this  asser¬ 
tion,  all  theoreticians  and  practitioners 
(that  we  are  aware  of)  would  agree. 
Beyond  that,  the  majority  of  theoretical 
and  practical  models  for  obfuscation  have 


at  least  two  other  requirements  for  the 
obfuscating  program  0(m):  semantic  equiv¬ 
alence  and  security. 

We  believe  security  may  be  provable  in 
some  circumstances  if  we  are  allowed  to 
expand  the  semantic  equivalence  require¬ 
ment  (in  other  words,  if  an  obfuscator  can 
change  the  [white-box]  structure  of  a  cir¬ 
cuit  so  that  [black-box]  input/ output  rela¬ 
tionships  of  the  original  circuit  P  are  also 
changed).  We  refer  to  black-box  transfor¬ 
mation  with  this  meaning  in  mind. 
Likewise,  the  obfuscator  may  change 
(white-box)  structure  in  such  a  way  so  that 
semantic  equivalence  with  P  is  preserved. 
We  refer  to  white-box  transformation 
with  this  meaning  in  view. 

Black-Box  Transformations 

Sander  and  Tschudin  [6]  were  one  of  the 
first  to  recognize  the  value  of  a  black-box 
transformation  as  a  means  to  hide  func¬ 
tional  intent.  In  discussing  black-box 
changes  to  P,  we  assume  there  are  certain 
programmatic  environments  where  the 
output  of  the  obfuscated  circuit  PTs  con¬ 
ducive  for  off-line  analysis  and,  therefore, 
open  to  the  possibility  of  recovering  the 
intended  output  of  the  original  circuit  P. 
In  certain  environments,  this  may  not  be 


possible.  Black-box  transformations, 
however,  may  be  necessary  to  achieve 
stronger  guarantees  of  security.  In  order 
to  achieve  a  useful  black-box  transforma¬ 
tion  by  some  specific  white-box  changes 
to  the  structure  of  a  circuit,  an  obfuscat¬ 
ing  operation  must  meet  two  require¬ 
ments: 

1.  Change  in  Black-Box  Behavior. 

The  functional  behavior  changes  for 
some  majority  of  values  in  the  domain 
x,  P(x)  =/  P’(x).  This  leaves  open  the 
possibility  that  some  transformations 
may  produce  equivalent  values  for  cer¬ 
tain  values  of  x. 

2.  Recovery  of  Black-Box  Intent.  In 

order  to  recover  the  original  functional 
output  of  P,  some  function  S(m)  must 
allow  inversion:  1 Y(x):P(x)—S(Py(x)). 
One  way  of  hiding  or  masking 
input/output  relationships  is  to  do  so 
through  transformation  that  keeps  the 
input/ output  values  hidden  in  plain  sight. 
We  refer  to  such  techniques  as  a  black-box 
refinement  of  the  original  circuit  P  and 
present  its  algorithmic  description  in 
Figure  3.  From  the  viewpoint  of  a  circuit 
and  its  corresponding  truth  table,  we  can 
visualize  at  least  five  distinct  operations 
that  may  be  a  part  of  a  black-box  refine- 


Figure  3:  Black-Box  Refinement 
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Figure  4:  Semantic  Transformation 


ment.  We  envision  that  all  five  would  be 
applied  in  a  probabilistic  manner  based  on 
configurable  properties  found  in  a  (secret) 
key.  If  we  let  X  represent  the  domain  of 
the  original  P  and  confine  it  to  a  fixed 
number  of  bits,  a  black-box  refinement 
may  do  any  of  the  following: 

1.  Add  input  bits  so  that  a  new  domain 
with  a  larger  possible  bit  string  X ’  is 
created. 

2.  Randomly  permute  the  input  bits 
themselves,  resulting  in  a  virtual 
reordering  of  the  bits. 

3.  Introduce  intermediate  gates  that 
would  result  in  new  truth  table 
columns  for  P’. 

4.  Introduce  a  random  number  of  out¬ 
put  gates. 

5.  Randomly  permute  any  of  the  output 
bits  themselves. 

Changing  the  full  input/ output  rela¬ 
tionships  of  a  circuit  may  truly  hide  the 
original  black-box  intent  of  a  circuit.  By 
composing  a  circuit  with  a  semantically 
strong  data  encryption  algorithm,  the 


resulting  program  exhibits  input/output 
relationships  with  desirable  cryptographic 
properties.  Figure  4  depicts  this  black-box 
change,  known  as  semantic  transformation. 

White-Box  Transformations 

We  define  a  structural  white-box  change 
to  a  circuit  as  a  change  to  the  topology  of 
the  underlying  directed  acyclic  graph, 
which  represents  the  circuit.  Topological 
changes  may  involve  textual  renaming  of 
signals  or  gates,  changing  the  Boolean 
function  type  of  particular  gates,  reorder¬ 
ing  input  or  output  signals,  introducing 
additional  inputs,  introducing  additional 
outputs,  concatenating  the  serial  compo¬ 
sition  of  the  entire  circuit  with  another 
circuit,  merging  the  parallel  composition 
of  the  circuit  with  another  circuit,  or 
replacing  one  or  more  gates  within  the 
circuit  with  a  functionally  equivalent  set 
of  gates. 

Figure  5  shows  the  traditional  mean¬ 
ing  of  obfuscation  as  understood  in  both 
theoretical  and  practical  study:  A  trans¬ 


formation  n>(P,  k)  —  P’t akes  as  input  a  cir¬ 
cuit  P  with  some  (possibly)  probabilistic 
information  embodied  in  key  k.  We  con¬ 
sider  any  random  choices  made  by  an 
obfuscation  process  to  be  part  of  this 
key.  The  output  of  w(-)  is  a  circuit  P}  that 
remains  functionally  equivalent  to  the 
original  circuit  P  and  represents  a  differ¬ 
ent  version  of  the  original.  Current 
obfuscation  research  centers  on  the 
transformation  algorithm  and  defining 
the  security  that  is  achieved  by  its  use. 

Reverse-Engineering  Attacks 

In  the  world  of  real  circuit  analysis,  the 
typical  goal  of  a  reverse  engineer  is  to 
recover  the  input/ output  of  the  circuit  in 
question  by  some  method  less  than  full 
exponential  enumeration.  As  we  have 
already  alluded  to  with  black-box  refine¬ 
ment  or  semantic  transformation,  such 
transformations  would  (at  a  minimum) 
prevent  this  form  of  reverse  engineering 
while  simultaneously  introducing  the  need 
for  output  recovery  in  order  to  maintain 
functional  utility.  There  are  a  number  of 
different  ways  to  discover  and  alter  the 
functionality  of  a  circuit.  The  term  tamper¬ 
ing  refers  to  broad  categories  of  circuit 
exploitation,  including  subversion,  modifi¬ 
cation,  and  reverse  engineering.  Reverse 
engineers  typically  target  reproduction  of 
a  circuit’s  functionality,  usually  for  capital 
gain  or  malicious  intent.  Specific  attacks 
can  be  roughly  categorized  as  brute  force, 
white-box/gray-box,  side-channel,  and 
fault  injection. 

Brute  Force  Attacks 

Brute  force  attacks  are  based  on  black-box 
circuit  behavior  and  are  performed  either 
while  the  circuit  is  in  its  natural  environ¬ 
ment  or  standalone  in  a  simulator.  Such 
attacks  can  be  categorized  as  either  general 
or  passive. 

•  General  black-box  attacks.  Tra¬ 
ditionally,  black-box  attacks  are  the 
first  and  simplest  means  to  reverse 
engineer  a  circuit.  Adversaries  glean 
black-box  behavior  by  enumerating  all 
possible  input  combinations  and 
recording  corresponding  outputs. 
Using  a  large  truth  table,  data  analysis 
algorithms — or  in  some  cases  visual 
inspection — the  adversary  may  re-cre¬ 
ate  the  underlying  Boolean  equations 
that  define  the  circuit’s  logic;  this  type 
of  attack  works  well  on  circuits  with 
well-defined  inputs  and  outputs. 

There  exists  potentially  2n  input 
combinations  to  fully  characterize  any 
combinational  circuit  and  potentially 
2n  +  m  or  more  input  combinations 
for  sequential  circuits  with  m  sequen- 


Figure  5:  White-Box  Transformation 
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tial  elements.  For  a  typical  circuit  with 
100  or  more  inputs,  a  conventional 
black-box  attack  is  not  practical  due  to 
an  enormously  large  search  space.  For 
example,  a  simple  64-bit  adder  with  a 
carry-in  pin  has  a  total  of  129  input 
pins  and  65  output  pins.  If  the  reverse 
engineer,  with  no  prior  knowledge  of 
the  circuit  applies  the  inputs,  it  would 
take  2129  attempts  or  2"  seconds, 
roughly  2  x  1022  years,  using  a  state-of- 
the-art  1  gigahertz  automatic  test 
equipment  costing  well  over  $1  mil¬ 
lion. 

•  Passive  attacks.  In  passive  attacks, 
adversaries  examine  circuits  in  their 
native  environment  (i.e.,  while  they  are 
being  used  in  an  actual  circuit).  Input 
and  output  pins  are  monitored,  using 
either  an  oscilloscope  or  logic  analyzer, 
and  data  is  recorded  giving  a  good  pic¬ 
ture  of  the  chip’s  functionality.  Typi¬ 
cally,  adversaries  use  passive  attacks  to 
provide  focus  for  later  black-box 
attacks  that  require  a  smaller  distribu¬ 
tion  of  input  values. 

White-Box/Gray-Box  Attacks 

In  physical  realizations,  white-box  attacks 
focus  on  the  structure  of  a  circuit.  An 
adversary  attempts  to  gain  access  to  the 
internal  nodes  of  a  circuit  without  having 
to  go  through  input/output  evaluation, 
allowing  a  better  functional  understand¬ 
ing.  Even  though  adversaries  may  risk 
destroying  delicate  circuit  internals,  these 
techniques  are  the  only  way  to  get  direct 
access  to  the  underlying  white-box  struc¬ 
ture  of  a  circuit  in  the  real  world.  In  order 
to  extract  white-box  descriptions,  adver¬ 
saries  focus  attention  on  silicon  character¬ 
istics  using  specific  technologies  such  as 
ion  beams  and  optical  equipment: 

•  Focused  Ion  Beam.  The  focused  ion 
beam  is  a  semiconductor  fabrication 
device  similar  to  the  scanning  electron 
microscope  (SEM),  but  it  uses  gallium 
ions  instead  of  electrons.  Unlike  the 
SEM,  it  has  a  destructive  effect  as  the 
gallium  ions  are  implanted  into  the 
sample  surface.  This  method  allows  an 
adversary  to  set  specific  intermediate 
nodes  to  specific  values  (0  or  1), 
including  modifying  existing  connec¬ 
tions  to  bypass  normal  input  signal 
propagation.  Likewise,  an  adversary 
does  not  have  to  rely  on  the  actual  out¬ 
put  of  the  circuit  in  order  to  examine 
intermediate  propagation  values. 

•  Optical  Equipment.  Optical  attacks 
rely  on  the  interaction  of  photons  with 
silicon  devices  and  take  two  forms: 
optical  probe  and  optical  attack. 
Optical  probing  focuses  on  circuit 


examination  by  looking  at  transistor 
states.  Adversaries  essentially  use  pic¬ 
tures  to  observe  signals  that  are  propa¬ 
gated  by  means  of  applied  input  values. 

Side-Channel  Attacks 

We  observe  that  even  circuits  that  may  be 
provably  secure  according  to  a  theoretical 
model — based  on  static  white-box  and 
dynamic  black-box  behavior — may  still 
leak  critical  information  relative  to  the  cir¬ 
cuit’s  function  (based  on  real-world  imple¬ 
mentation  issues).  Rather  than  use  brute 
force  (to  glean  black-box  behavior)  or 
physically  probe  the  internals  of  a  circuit 
(to  glean  white-box  and  gray-box  behav¬ 
ior),  side-channel  attacks  use  secondary 
information  to  create  a  picture  of  circuit 
functionality.  Side  channels  are  areas  of  a 
circuit  that  leak  unintended  information. 
They  include  power  consumption  and 
timing  analysis: 

•  Power  Consumption.  Power  con¬ 
sumption  attacks  mainly  focus  on 
breaking  cryptographic  schemes.  The 
concept  is  that  through  an  examina¬ 
tion  of  the  power  used  by  a  circuit,  the 
underlying  encryption  algorithm  can 
be  found.  This  approach  gives  an 
attacker  insight  into  the  data  values 
that  are  being  manipulated  on  a  chip.  It 
is  possible  to  then  correlate  this  col¬ 
lected  data  to  known  functions  in 
order  to  see  exactly  what  is  happening. 

•  Timing  Analysis.  With  brute  force 
attacks,  synchronous  circuits  add  addi¬ 
tional  complexity  in  the  reverse-engi¬ 
neering  process  due  to  the  timing  con¬ 
straints  that  are  introduced.  Timing 
attacks  focus  on  taking  the  circuit  out¬ 
side  of  normal  parameters  by  modify¬ 
ing  the  speed  of  the  clock,  either 
speeding  it  up  or  slowing  it  down. 
Because  timing  is  linked  directly  to 
real-world  physical  implementations  of 
various  circuit  technologies,  our  exist¬ 
ing  obfuscation  framework  requires 
additional  information  regarding 
structural  characteristics  of  the  circuit 
implementation. 

Fault  Injection 

Fault  injection  is  a  generic  term  describing 
the  injection  of  faults  into  digital  systems 
using  a  variety  of  attacks:  raising  voltage 
higher  or  lower  than  system  tolerances, 
inducing  voltage  spikes,  or  introducing 
clock  glitches.  An  adversary  may  use  any 
of  these  methods  to  cause  the  system  to 
malfunction  with  intentions  of  revealing 
information  useful  in  further  attacks.  The 
adversary  performs  fault  injection  dynam¬ 
ically  at  circuit  run-time  combined  with 
power  analysis  techniques.  Encryption 


Software  Defense 
Application 

Considering  the  proliferation  of  embed¬ 
ded  systems  with  reprogrammable  hard¬ 
ware  components  in  both  commercial 
and  military  sectors,  we  can  readily  show 
the  impact  of  malicious  activity  geared 
to  reverse  engineer,  tamper,  or  copy  crit¬ 
ical  technologies  resident  in  those  sys¬ 
tems.  Both  the  DoD  and  industry  have 
interest  in  understanding  how  to 
describe  and  measure  candidate  protec¬ 
tive  measures,  whether  they  derive  from 
hardware  anti-tamper  realizations  or 
software-based  techniques.  This  article 
deals  specifically  with  the  characteristics 
of  protection,  possible  transformations, 
and  the  delineation  of  malicious  attacks. 


algorithms,  such  as  the  Advanced 
Encryption  Standard  (AES),  provide 
strength  against  brute-force  key  discovery 
from  black-box  behavioral  analysis. 
However,  an  adversary  may  use  fault  injec¬ 
tions  with  realized  AES  circuits  in  order  to 
reduce  encryption  strength  via  key-space 
reduction.  This  exploit  requires  internal 
circuit  access  and  reduces  the  goal  of  the 
adversary  from  using  brute-force  methods 
to  interrupt  the  successful  encryption/ 
decryption  process  itself. 

Conclusion 

Given  the  current  trend  of  reprogramma¬ 
ble  embedded  devices  within  the  DoD 
and  industry,  attention  needs  to  be  refo¬ 
cused  on  the  benefits  or  measurability  of 
software  protection  applied  to  this 
domain.  Modern  reconfigurable  embed¬ 
ded  systems  now  require  us  to  consider 
circuits  as  software  and  the  tamper  meth¬ 
ods  applicable  to  physical  circuits  as  new 
threats  to  a  broadened  definition  of  soft¬ 
ware.  This  article  has  presented  a  brief 
overview  of  the  characteristics,  transfor¬ 
mations,  and  attacks  possible  in  the  realm 
of  software  implemented  as  circuits  on  an 
embedded  system.  Ultimately,  we  must 
turn  our  attention  to  the  protection  of 
critical  technology  resident  in  such  an 
embedded  system,  mindful  of  the  possible 
threats  and  techniques  at  our  disposal.^ 
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